RoclET– A Tool for Wrestling with OCL Specifications

In this paper, we describe the architecture and the functionality of our own OCL tool called RoclET. Besides standard features of OCL tools such as editing of class and object diagrams and parsing of OCL assertions (invariants, pre-/post-conditions), our tool supports also the evaluation of OCL constraints in a given system snapshot (object diagram), refactoring of UML/OCL models, and impact analysis. RoclET is deployed in form of an Eclipse plugin. 1 Precise Modeling with OCL The Unified Modeling Language (UML) is today the most popular object-oriented modeling language for software systems. UML is in the first place a graphical notation what makes software models easily accessible by humans. UML diagrams can give a good overview on the modeled software system, but there is a lack of expressive power once the details of the software system have to be captured as well. A prevailing practice to resolve this problem is to add comments to UML diagrams and to clarify the intended meaning using natural language. Such informal comments, however, do not alter the formal meaning of the model and are ignored by tools when processing the model, e.g. in order to generate code. Another disadvantage is, that reading informal comments can become easily a hard and also ambiguous task once the comments are a little bit more complex. The Object Constraint Language (OCL), see [1] for both an introduction and the language specification, is a textual language with formal syntax and semantics. OCL constraints capture a wide range of details that software developers wish to express in precise software models. The main application scenario are UML class diagrams. Here, OCL constraints can express conditions that should be obeyed in each system state (invariants) and contracts for system operations (pre-/post-conditions). Most of the current OCL tools – USE [2], Octopus[3], Dresden OCL Toolkit [4] and OCLE [5] being the most influential ones – were developed in academia. Whereas almost each tool offers, besides parsing facilities for OCL, a functionality to generate implementation stubs out of UML/OCL models, relatively little 1 RoclET is freely available from www.roclet.org effort has been made so far to analyze the OCL constraints themselves, to provide functionalities for automatic constraint simplification, for refactoring, for analyzing of which impact a (small) change in a snapshot on the validity of a given OCL invariant has. RoclET aims at providing facilities for a painless authoring, processing and analysis of OCL constraints. The main functionalities of RoclET are: – Parsing and type analysis – Evaluation in a given object diagram (applying the technique described in [6]) – Refactoring of UML class diagrams including necessary changes on attached OCL constraints (see [7]) – Blocking state analysis for operation contracts – Impact analysis of changes made in the object diagram wrt. the validity of OCL constraints (this feature is based on the pioneering work of Cabot and Teniente [8, 9]) 2 Architecture of RoclET We have chosen a 3-layer architecture for RoclET (comp. Fig. 1): presentation layer, application layer and data layer. The presentation layer consists of the editors and views the user interacts with. Due to a lack of flexible editors for class and object diagrams, we have decided to implement our own editors. The presentation layer has direct access to the data layer where the models are stored in a repository as instances of the UML/OCL metamodel. Currently, the versions UML 1.5 and OCL 2.0 are supported. RoclET’s functionalities are implemented in the application layer, mainly in form of transformation rules written in QVT. These transformations work on the repository and usually alter it directly.